大家週四好，今天我們要繼續 SRE 方法論的第五條：變更管理，這裡是今天讀的原文出處：Introduction，往後偷翻幾頁發現這週應該可以把第一章完成（歡呼！！！），那我們開始囉！

書中提到變更管理的最佳實踐是使用自動化來達成漸進式部署，並且能在檢測到問題時，進行版本的回滾。首先來了解一下第一個名詞吧！

什麼是漸進式部署？

漸進式發布機制是一種軟體開發和部署方法，旨在逐步將新功能、修復和改進應用程式或服務引入到生產環境中。

它的主要目的是降低風險並確保系統的穩定性和可靠性。 在漸進式發布機制中，新功能不是一次性全部引入，而是分批次或分階段引入。

首先，新功能會在一個小規模的測試環境中進行測試和驗證，一旦確定新功能能夠正常運作且不會對系統產生重大影響，就可以將其引入到生產環境的一小部分用戶中。 這種逐步發布的方式使得開發團隊能夠實時監控和評估新功能的性能和反饋。如果出現任何問題，可以及時進行修復或回滾。

如果整理成流程圖會像下面這樣：

復盤時間

檢視了一下現在在 K8s Deployment 內定義的回滾計畫：

// 定義 Deployment 回滾策略
const strategy = {
  type: 'RollingUpdate',
  rollingUpdate: {
    maxSurge: IntOrString.fromString('25%'),
    maxUnavailable: IntOrString.fromString('25%'),
  }
}

• type: 部署策略的類型。這裡使用的是 RollingUpdate，RollingUpdate 策略會逐步更新每個 Pod 的實例。
• maxSurge: 允許額外創建多達當前實例數量的 25% 作為暫時的額外實例（maxSurge: 25%）。
• maxUnavailable: 確保在更新過程中至少有 25% 的 Pod 實例是可用的（maxUnavailable: 25%）。

從 GCP 的介面上看起來就會像這樣下圖正在部署新版本 20：

若成功部署，則會將流量移至新版本 20 上！

後記

今天研究了什麼是漸進式部署與回滾計畫，接下來的內容是「需求預測和容量規劃」！那麼就明天見拉！掰噗！